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PL360, due to the efforts of Niklaus Wirth (ref. 1), is a phrase-structured programming 
language which provides the facilities of a symbolic machine language for the IBM 360 com- 
puters. It is defined by a recursive syntax and is implemented by a syntax-directed compiler 
consisting of a precedence syntax analyzer and a set of interpretation rules, as discussed by 
Wirth and Weber in reference 2. 

Syntax-directed documentation refers to an automatic process which acquires program- 
ming documentation through the syntactical analysis of a program, followed by the inter- 
rogation of the originating programmer. This documentation can be dispensed through re- 
ports or File query replies when other programmers later need to know the program structure 
and its details. 

The interrogation of an originating programmer consists of a relisting of the program 
text, with certain syntactic entities, which are classified as documentation units, set off ty- 
pographically in lines and labeled with an ordinal coordinate system and a sequence of ques- 
tions about these documentation units. These questions are generated automatically by com- 
pleting prestored skeleton questions with coordinates and/or programmer-generated identifiers. 
The programmer’s responses to the questions are stored and indexed to these documentation 
units for retrieval. 

A key principle in what follows is that the programming documentation process is man- 
aged solely on the basis of the syntax of programs. The semantics of the documentation, as 
embodied in programmer responses to interrogation, are not analyzed by the process except 
in mechanical ways such as keyword indexing. In this way, a programmer’s responses are 
treated as “black messages” in the process, in analogy to the idea of a “black box.” That is, 
a programmer’s responses are requested, accepted, stored, and later retrieved with no seman- 
tic analysis of their contents. 

SYNTACTIC PRELIMINARIES 

We use the notation and definitions for PL360 in reference 1. In defining documenta- 
tion units and lines, the following device is used. First, denote the grammar in reference 1 
by G, which defines the language PL360, L(G). This grammar G will be transformed Finitely 
into a new grammar G* such that 

L(G*) = L(G) 


•Copyright © 1970, Association for Computing Machinery, Inc. Reprinted by permission. 


105 



106 


AUTOMATED METHODS OF COMPUTER PROGRAM DOCUMENTATION 


<BlOCK> 

<CA SE ST> 

<FUK ST> 

<FUNC 0ECL7> 

<FUNC IO> 

<FUNC ST> 

< WJ TO ST> 

< IF THEN ELSE ST> 
< I F THEN ST> 

<K REG ASS> 

<NOLL ST> 

<PROC DECL > 

<PKOC 1D> 

<PROGR AM > 

<SEG OECL> 

<STN OC2> 

<r CELL A ss> 

<T DEC L 7> 

<MHl LE ST> 


<BLOCKBQOY> END 
<CA SE SE0> END 

FOR <ASS STE P> <L I N I T> <O0> <STATEMENT#> 


<FUNC1> I 
GOTO <IO> 

IF <COND THE N> <TRU6 P ART > <STATEMENT»> 
IF <CONO THE N> <ST AT EMENT •> 


<PROC HD6> <STATEKENT*> 

<SEG ME AO> BASE <K REG> 

<T CELL > :» <K R£G> 

<MHILE> <CONO DO> <STATEMENT*> 


Figure 1.— Documentation units. 

G k , we can define a new production 64) ::= X and 
any rule we please in G k , to get a grammar . 
construction. Then, we consider a sequence 

G = G°, G l 


and such that G* contains syntactic en- 
tities we want to classify as documenta- 
tion units and use to define lines. 

The basis for the transformation of 
G into G * is a finite number of elemen- 
tary steps as follows. If X is any finite 
sequence of tokens and/or syntactic en- 
tities which occurs as part of the right 
side of a production rule in a grammar 
G k , and C A) is not a syntactic entity in 
substitute C4> for X in the right side of 
It is clear that L(G k+ 1 ) = L(G k ) by this 

, G n = G* 


where n is the (finite) number of additional syntactic entities we want to be defined in G* 
which are not in G. 

We note that even though additional syntactic entities can easily be introduced in a 
grammar while retaining the identical language, the question of keeping it a precedence 
grammar (ref. 2) is a delicate matter. This general point is not pursued here. However, we 
use only transformations which label the entire right side of a rule; in this case the grammar 
obviously retains its precedence properties. 

In what follows, the grammar G is augmented to G* just to provide a basis for invoking 
additional interpretation rules which define documentation files and generate questions. It 
will also be apparent that the same device can be useful in extending syntax processing be- 
yond documentation to questions of execution control and dynamic storage allocation in 
multiprogramming operating systems. For example, better use of core may arise if core is 
allocated to the machine code responding to syntactic entities such as “for statements” and 
“while statements” rather than simply arbitrary “pages” of machine code which may break 
up such natural units of execution. 


DOCUMENTATION UNITS 

We classify as a documentation unit any right-hand side of a rule which reduces to one 
of the following syntactic entities in reference 1 : 

(SIMPLE STATEMENT) 

(STATEMENT) 

(DECL) 

(PROGRAM) 

There are 19 such documentation units given in figure 1. If the right-hand side is already 
defined in G, it is used directly. Otherwise, a new syntactic entity is defined, with the under- 
standing that G is augmented by each such definition, as described above. 
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In effect, this classification of documentation rules is a convenience for identifying 
productions whose recognition in an analysis corresponds to having additional interpretation 
rules that deal with documentation processing. 

Given a PL360 program, we consider every realization of such documentation units, 
which can be structured on the basis of syntactic membership, as follows. A documentation 
unit is a member of a second documentation unit if its program text is a subset of the pro- 
gram text of the second. It is an immediate member if it is not a member of any third docu- 
mentation unit, itself a member of the second. 

The relation of immediate membership defines a nested structure of documentation 
units in a program, beginning with the program itself as the highest level documentation 
unit and continuing through “blocks,” “compound statements,” etc., to “single declarations” 
and “single statements” at the lowest levels. This nested structure can also be described as a 
rooted tree, with the program as the root, and other documentation units as remaining inter- 
mediate and endpoint nodes in the tree. 

Notice any given statement or declaration may be included in the program text of 
many documentation units. In fact, every documentation unit is a member of the program 
and of every other documentation unit whose text contains it. 

SYNTAX-DEFINED PROGRAM LISTINGS 

Next, we consider the question of listing programs written in PL360 in a standard way 
for readability and referencing during programmer interrogation and later examination. 

When programmers make an informal effort to arrange their programs for readability, they 
typically start each documentation unit, as defined above, on a new line and use indentation 
to correspond in a general way with syntactical nesting in the program. We recognize that 
the problem is a subjective one, but we give a syntax-defined listing algorithm which is be- 
lieved to satisfy the intuitive intentions observed in informal programming efforts. 

For the purpose of typographical listing, we partition a PL360 program or procedure 
into a string of substrings. Each substring is to be a printed line, and the string of lines con- 
stitutes a listing of the program. Associated with each line are two numbers: one which 
specifies its order in the program or procedure, and one which corresponds to the indenta- 
tion (or starting column) of the line. If a line exceeds the width of paper available, its con- 
tinuation is further indented a standard amount. 

The partition of a PL360 program or procedure into lines is defined by marking the 
starting text for each documentation unit, and each label, BEGIN, END, ELSE, and . (dot) 
symbol. The lines are numbered consecutively. The indentation number is the level of nest- 
ing of the documentation unit it begins, if any, based on syntactic membership as described 
above. The only lines not beginning a new documentation unit are BEGIN (in CASE state- 
ments), END, ELSE, and . (dot). In each case they are indented according to the level of the 
documentation unit which they help define. Labels are given the indentation level of the 
program or procedure being listed. 

To refer to a line from outside a procedure, we qualify the line numbers with the pro- 
cedure name. While the concept of program is defined in PL360, no provision is made for 
naming a program in the syntax. 
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<BLOCK> 

01 PURPOSE OF BLOCK 1 COORD INATESt? 

SI BLOCK ( COORDINATE Si IS TO (RESPONSE). 

<CASE $T> 

01 PURPOSE OF CASE STATEMENT (COORDINATES!? 

51 CASE STATEMENT (COORDINATES) IS TO (RESPONSE). 

02 CASE SELECTED AT (COORDINATE)? 

5 2 CASE SELECTEO AT (COORDINATE) IS (RESPONSE). 

<FOR ST> 

U l PURPOSE OF FOR STATEMENT I COORD) NATES ) ? 

51 FOR STATEMENT (COORDINATES) IS TO (RESPONSE!. 

U 2 FOR CONDITION AT (COORDINATE)? 

52 FUR CONDITION AT (COUROINATE) IS TO (RESPONSE). 

<fUNC OECL ?> 

01 FUNCTION OPERATION AT (COORDINATE)? 

si function operation at (coordinate) is to iresponset. 

<func io> 

01 PURPOSE OF FUNCTION STATEMENT AT I COORDI NAT E I ? 

SI FUNCTION STATEMENT AT (COORDINATE) IS TO (RESPONSE). 

<func sr> 

Ul PURPOSE OF FUNCTION STATEMENT AT (COORDINATE)? 

SI FUNCTION STATEMENT AT (COORDINATE) IS TO (RESPONSE). 

<GOTq ST> 

01 CO TO HHERE AT I COGROI NATE I ? 

SI AT (COORDINATE) CONTROL GOES TO (RESPONSE ! . 

OF TmEN ELSE Sl> 

01 PURPOSE OF IF THEN ELSE STATEMENT (COORDINATES)? 

51 IF THEN ELSE STATEMENT AT (COORDINATES) IS TO (RESPONSE). 

02 IF CONOITION AT (COORDINATE)? 

5 2 IF CONOITION AT (COORDINATE) TESTS (RESPONSE). 

<If THEN ST> 

01 PURPOSE OF IF THEN STATEMENT (COORDINATES)? 

51 IF THEN STATEMENT (COORDINATE SI IS TO (RESPONSE). 

U 2 IF CONDITION AT ( COORD I NA f E ) 7 

52 IF CONDITION Al ICCOROlNATE) TESTS (RESPONSE). 

<K REG ASS > 

01 VALUE OF <<I0>) AT (COORDINATE)? 

SI VALUE OF (<I0>I AT (COORDINATE) IS (RESPONSE). 

<NULL Sl> 

01 PURPOSE OF NULL STATEMENT AT (COORDINATE)? 

51 NULL STATEMENT AT (COORDINATE) IS TO (RESPONSE). 

<PKOC OfcCL > 

01 AUTHOR OF PROCEDURE <<IO>>? 

si author of procedure i < 1 o> » is (response). 

02 PURPOSE OF PROCEDURE? 

52 PRDCEOURF (<ID>> IS TO (RESPONSE). 

UJ INITIAL OATA? 

53 INITIAL DATA OF PROCEUURE l<10>) IS (RESPONSES). 

ON PROCESSING LOGIC? 

S* PROCESSING LCGIC OF PROCEDURE (<I0» IS TO IRESPONSEI. 

05 FINAL OATA? 

55 FINAL OATA OF PROCEDURE l<10>) IS (RESPONSE). 

06 REFERENCES? 

56 REFERENCES FOR PROCEDURE (<10>l ARE (RESPONSE). 

<PROC I D> 

0) PURPOSE OF PROCEDURE STATEMENT AT (COORDI NATE I? 

SI PRUCEDURE ( <PROC !0>> AT ( COORDINATE I IS TO (RESPONSE). 
<PRUGRAM> 

01 AUTHOR OF PROGRAM KID>>? 

51 AUTHOR OF PROGRAM KIO>) IS IRESPONSE). 

02 PURPOSE OF PROGRAM ? 

52 PROGRAM ( < I 0 > ) IS TO (RESPONSE). 

03 INITIAL DATA? 

53 INITIAL DATA OF PROGRAM (<I0>) IS (RESPONSE). 

06 PROCESSING LOGIC? 

S6 PROCESSING LOGIC OF PROGRAM (<I0>) IS TO (RESPONSE). 

05 FINAL DATA? 

55 FINAL OATA OF PROGRAM (<|0>) IS IRESPONSEI. 

06 REFERENCES? 

56 REFERENCES FOR PROGRAM (<I0>) ARE (RESPONSE). 

<SE6 DECO 

NO QUESTION 
NO STATEMENT 

<SVN DC2> (FOR EACH IDENTIFIER DECLARED) 

01 SYNONYM (<I0» TO (<ID>) AT (COORDINATE)? 

SI SYNONYM (<I0>) TO ( < 1 0 > I AT (COORDINATE) IS IRESPONSE). 

<T CELL A S$> 

01 VALUE OF I < I D> ) AT ( COORO I NATE I ? 

SI VALUE OF I <1 D> ) AT (COORDINATE) IS IRESPONSEI. 

<f OECL 7 > 

01 I <1 0>) AT (COORDINATE)? 

SI I < 1 0 > I AT (COORDINATE) IS IRESPONSEI. 

<WM|lE ST> 

Q 1 PURPOSE OF WHILE STATEMENT (COOROI NATESI 7 

51 WHILE STATEMENT I COORO I NATE S I IS TO IRESPONSEI. 

02 WHILE CONDITION AT (COORDINATE) ? 

52 WHILE CONDITION AT ( COOROI NATE I TESTS (RESPONSE!. 


Figure 2.— Skeleton question/statements for 
documentation units. 


For convenience, we introduce a 
new basic symbol PROGRAM and the 
redefinition 

<PROGRAM> :: = 

PROGRAM <ID> (STATEMENT) 

which permits the naming of programs and 
reference to documentation units by line 
numbers, qualified by program names. 

CANONICAL DATA FILE 

For convenience in documentation 
processing, we define a canonical data file 
as consisting of a record for each documen- 
tation unit of a program or procedure dec- 
laration. Its function is not only to store 
relationships between various syntactic en- 
tities but also to provide data for driving 
interrogation, report generation, and query 
processing concerning the program or pro- 
cedure. Each record describes three proper- 
ties of the documentation unit: its coordi- 
nates in the program text, its syntactic type, 
and an identifier list. The coordinates are the 
first and the last lines of the documentation 
unit (which may be the same when text is 
contained in a single line). The syntactic 
type is the entity identified as a documen- 
tation unit in figure 1 . The identifier list 
depends on the syntactic type— denoting 
identifiers which are declared, assigned 
values, used in assigning values, used in con- 
trol logic, etc. 

It is clear that a deeper syntactical 
structure, described only informally here, 
is relevant below the generic level of 


documentation unit. For example, the identifier list itself is definable in terms of productions 
within a documentation unit, and such productions determine whether each identifier is 
being declared, assigned a value, used in a computation, used in control logic, etc. Thus the 
additional interpretation rules required for documentation processing are distributed through- 
out the syntax, all the way down to the identifier level, but are not discussed in detail now. 
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SYNTAX-DIRECTED INTERROGATION AND RESPONSE EDITING 

We consider an automatic interrogation process, which uses the canonical data file to 
complete prestored skeleton questions with program text coordinates and/or identifiers. 

The interrogation process proceeds through the file, a record at a time, and generates a 
series of questions from each record, depending on the syntactic type and identifier list 
found therein. The responses to such questions, made by the programmer, are indexed to 
the records which generated them. 

A set of skeleton questions associated with different documentation units in PL360 is 
displayed in figure 2. At the end of each interrogation, the programmer is given a final oppor- 
tunity to volunteer any additional information. 

Associated with each skeleton question in figure 2 is a skeleton statement which con- 
tains the programmer’s response to that question as one of its parts. These statements, filled 
in with responses and other data from the canonical data file, as shown, represent basic unit 
messages which can be assembled into reports and query replies. 

The construction of skeleton questions and skeleton statements to elicit and edit pro- 
grammer responses is a substantial and still open problem. It is evident that careless ques- 
tioning can bury programmers in questionnaires and alienate them to the whole idea. Limited 
experience (refs. 3 and 4) has indicated that skeleton questions should be terse and highly 
selective. An involved question, which seems reasonable to read once or twice, can have a 
very negative effect on a responder when repeated many times, even though this kind of 
question requires no more effort to answer than a terse one. Thus a first principle in question 
construction is that the burden of understanding what the question means must be put into 
a separate orientation course, outside the interrogation itself, and the questionnaires must 
be kept as short as practicable. 

A second principle in question formation is that program text itself must be depended 
upon for later programmer reference. The questions and responses are intended to illuminate 
the program text, not to replace it. Otherwise, questions become too involved with points in 
plain sight in the program text. 

Similarly, the order of questioning is also important. Some experience indicates that a 
“top-down” sequence is a better basis for questioning than “bottom-up.” Fortunately, due 
to the structure of PL360, interrogating documentation units in the order in which their 
starting text appears gives a top-down approach, which seems easy to follow and reference 
from both syntactic and typographical viewpoints. 

It has been suggested that the matter of question formation might be related to the 
problem of proving the correctness of programs. Naur (ref. 5) discusses an approach to prov- 
ing the correctness of programs by “general snapshots,” e.g., the state of all variables at 
various points in programs. These general snapshots could be defined at the entries to and 
exits from documentation units. This raises the possibility of forming such questions as: 
“What variables can be modified in this documentation unit?” and “What relationships be- 
tween the variables must hold (a) on entry to or (b) on exit from this documentation unit?” 

At the moment, no suitable way of forming such deeper questions for automatic in- 
terrogation is known. But this is an area where future progress may be possible. 
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DOCUMENTATION PRODUCTS 

As already noted, two principal documentation products are— 

Documentation reports: complete descriptions, in a prescribed format, of programs or 
procedures. 

Query replies: partial reports in response to queries made by programmers familiar with 
programs or procedures to probe specific details. 

It is to be noted that both interrogation and query reply processing lend themselves to 
conversational techniques (ref. 4). The canonical data file can be used to drive a conversa- 
tional interrogation of a programmer quite directly. Similarly, the same file, with an asso- 
ciated file of indexed programmer responses, can be used to generate “computer-assisted 
instruction courses” automatically when the subjects are particular PL360 programs or 
procedures. 

It should be emphasized that the documentation discussed is addressed to a programmer 
who understands PL360 and will be reading the PL360 text concurrently. The documenta- 
tion products are not intended to replace this text as the ultimate authority of what the 
program does. Rather these products are intended to supplement the program text with 
perspective, motivation, identifier meanings, processing rationale, etc. In this way it is ex- 
pected to increase the power and precision with which a programmer can deal with the pro- 
gram text, to modify it, to verify its functional logic, and to assure the integrity of a pro- 
gramming system containing it. 

The documentation products will not themselves fill needs of higher level documenta- 
tion related to user directions, instruction manuals, etc. However, technical writers con- 
cerned with such higher level documentation should find these products extremely useful 
as source material. 

DOCUMENTATION REPORTS 

We define a standard documentation report with three parts: 

( 1 ) Program text 

(2) Edited responses 

(3) Cross-references 

The program text is the relisted, labeled text used in interrogation. The typographical 
arrangement of this relisting itself shows the overall syntactic structure of the program and/ 
or procedures. 

The edited responses, listed in the same order as the questions which generated them, 
proceed through the text in a systematic way so that one can refer back and forth between 
the relisted text and the responses efficiently in reading them together. It is expected that 
the program text and edited responses will be read together by programmers. It would be 
feasible to intersperse the responses, as comments, in the text, but it seems more desirable 
to treat them as separate documents with easy interference facilities. 

In fact, as a programmer becomes more familiar with the details of a program, the 
presence of extensive comments tends to inhibit the visual perception of program structure 
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and logic: first, by simply taking up space and expanding the size of material to be looked 
at; and second, by interrupting and masking typographical features corresponding to the 
syntactical structure of the program. 

The cross-references assemble identifer, function, and procedure usage into cross- 
reference tables. Identifier usage in the text is categorized into “declared,” “assigned,” 

“used in assignments,” and “used in control.” It is expected that these cross-references serve 
most of a programmer’s needs for evaluating and/or modifying small programs or procedures; 
for example, to assure that all implications of a changed data declaration are accounted for. 

Note that such cross-references can be assembled directly by interpretation rules dur- 
ing program analysis at the time various productions are recognized but then are referred to 
only informally here. 

One particular use of cross-references in PL360 of some potential importance is the 
recognition of commonality of data references. In particular, the use of identifiers synony- 
mous with hardware registers, which add considerably to the readability of PL360 text, can 
be found with the aid of such cross-references. 

QUERY REPLIES 

It is possible to generate a documentation report for any size system of programs or 
procedures, of course, as a sequence of documentation reports of all its component pro- 
cedures and programs. However, where documentation reports for a small procedure can be 
examined rather easily for any information in it, the human eye and mind cannot take in 
the scope and details of a large system so readily. Thus simply listing a documentation re- 
port of a large system, while perhaps of value as a hard-copy reference, is still unsatisfactory 
for a programmer seeking to understand, modify, or augment a procedure interacting with 
many other parts of the system. This may be even more critical for a system manager, who 
is trying to verify the correctness of a new procedure and to assure that no ill effects occur 
in the system in accepting that new procedure. 

This very problem has motivated the foregoing acquisition of documentation as re- 
sponses to specific questions so that the documentation can be indexed down to the state- 
ment and identifer level. Thus the documentation in a large system can be enhanced by the 
capability for automatic selective retrieval and analysis of documentation. In this sense, the 
problem of a programmer is not so different from other information systems where data 
must be stored for retrieval from many points of interest. 

A query language for accessing the type of data in these documentation files can be 
readily imagined and is not defined in detail here. Its output could simply be a selection of 
edited responses, as defined above. As already noted, such a query capability would lend 
itself well to conversational methods of programmer access to the documentation. Its capa- 
bilities should include, for any given documentation unit, finding identifier usages, extract- 
ing “purpose of’ responses for all its members, identifying all branch points, and locating 
all references to keywords in responses. 

PROGRAMMER ADAPTATION 

In the final analysis, it is expected that the important issues in making such a syntax- 
directed documentation process effective will be the soundness of the structural approach, 
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rather than niceties of question phras- 
ing or report formation. This is be- 
cause programmers, as human beings, 
have a large capacity to adapt to mat- 
ters of English usage but a small capac- 
ity to deal with extended program syn- 
tax structures in detail. 

In the interrogation process, pro- 
grammers will soon learn how to phrase 
their responses gracefully in matters of 
English usage such as parts of speech 
and tense simply by examining the 
edited responses which their answers 
generate. Also, they will learn how the 
details of their rationale should be al- 
located among responses by experi- 
ence in interrogation and by examin- 
ing the resulting documentation 
reports. It will still take ability to doc- 
ument programs, but an ability which 
is adapted to the automatic process 
being used to acquire and dispense 
the documentation. 

For example, a programmer new 
to the process may respond to a ques- 
tion about a block by going into the 
details of statements inside the block. 
After going through several interroga- 
tions and realizing he will be ques- 
tioned about the included statements 
later anyway, he will learn to confine his response about the block to the block as a unit. 
Similarly, by learning that conditions for branching IF statement will be taken up sepa- 
rately, a programmer, following the treatment of the IF statement as a unit, will address his 
response to the IF statement itself. 

In using the documentation of others, a programmer, from his own experience as an 
originating programmer, will be aware of the questions which generated the responses. He 
wiii know, simply by examining program text himself, what questions were asked about any 
documentation unit or identifier he may be interested in and where they were asked. Thus 
he can exert considerable intelligence in selective queries of documentation files. 

AN EXAMPLE 

Figures 3 to 9 simulate the foregoing methods on a sample PL360 procedure, found in 
reference 1, showing the relisting and interrogation, the canonical data file, a set of responses, 
a documentation report, and, finally, a set of query replies. 


PROCEDURE NAG I C SQUARE IR6I; 

CUMMENT IMIS PROCEDURE ESTABLISHES A HAGIC SQUARE OF QROER Nt IF N IS 

000 ANO 1 < N < 16. X 1 S THE MATRIX IN LINEARIZED FORM. REGISTERS 
R0...R6 ARE USED, AND REGISTER RQ INITIALLY CONTAINS THE PARAMETER 
N. ALGORITHM 1 IB COMM. ACM 5 IAUG. 19621 l 

BEGIN SHORT INTEGER NSUR; 

INTEGER REGISTER N SYN AO, I SYN R1 , J SYN R2, XX SVN R3, 

IJ SYN K 4 , K SYN RSl 

NSQR n; R1 :• N • NSQR; NSQR :* RlJ 

1 :* N ♦ 1 SHRL 1; J S* n; 

FOR X :» 1 STEP 1 UNTIL NSQR DO 

BEGIN XX :■ I SHLL 6; IJ S* J SHLL 2 ♦ XXI XX J « X 1 ( J ) 5 
IF XX — 0 THEN 
BEGIN I :• I - I ; J s» J - 2; 

IF 1 < 1 THEN I :« I ♦ N; 

IF J < 1 THEN J :« J ♦ N; 

XX :» I SHLL 6; IJ :* J SHLL 2 * XX; 

END; 

x| I J) :> Kt 

I :■ I ♦ l; IF I > N THEN 1 :» I - NJ 

J :« J ♦ i; IF J > N THEN J s« J - N{ 

ENu; 

END 


Figure 3.— Procedure Magicsquare (ref. 1, p. 53). 


1 PROCEDURE MAGICSQUARE (K6); 

2 BEGIN 

3 SHORT INTEGER NSQR; 

4 INTEGER REGISTER N SYN RQ, I SYN Rl , J SYN R2, XX SYN R3, 
IJ SYN R 4 , K SVN R5; 

5 NSQR :« N; 

6 Rl :* N • NSQR; 

7 NSQR :« Rl; 

d I :* N ♦ 1 SHRL 1; 

9 j s« n; 

10 FOR K 1 STEP I UNTIL NSQR 00 

11 BEGIN 

12 xx :* I SHLL 6; 

13 IJ :■ J SHLL 2 ♦ XX; 

14 xx :« XII j); 

15 IF XX 0 THEN 

lb BEGIN 

17 I :• I - l; 

lu J :« J - 2; 

19 IF 1 < 1 THEN 

20 I :« 1 ♦ N; 

21 IF J < l THEN 

22 J :■ J ♦ n; 

23 XX I SHLL 6; 

24 IJ :■ J SHLL 2 ♦ XX; 

25 END; 

26 XI IJI :• K; 

21 I *• I ♦ U 

28 IF l > N THEN 

29 I *» I - N; 

30 J :■ J ♦ l; 

31 IF J > N THEN 

32 J I* J - N! 

33 END; 

34 END 


Figure 4.— Syntax-defined listing of Magicsquare. 
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CUUR- DUC . IDENTIFIERS 

DINARS UNIT 

1.34 12 ►< AG 1 C S'JUARE , kb 

2.34 1 

3*3 ItJ NSQR 

A , A 16 N ■ I * J, XX, I J, K 

5.5 17 NSUK, S 

6.6 10 M. N, NSQR 

7.7 17 NSUK, R 1 

b,0 10 I , N 

9,9 10 J, N 

10*33 3 A, NSQR 

11*33 i 

12.12 10 XX, 1 

13.13 10 1 J. J, XX 

14.14 10 XX, X(1J) 

15.25 9 XX 

16.25 I 

17,1/ 10 1,1 

1 8, Id 10 J, J 

1 9* 20 9 I 

20, 20 10 I , 1 . N 

21.22 9 J 

22.22 10 J, J, N 

23.23 10 XX. I 

24.24 10 IJ, J, XX 

20 . 26 17 X, I J, K 

27.27 lu 1, 1 

26.29 9 I, N 

29.29 10 I. 1, N 

30.30 10 J, J 

31.32 9 J. N 

32.32 10 J i J, N 


Figure 3 is a PL360 procedure named by Magic- 
square, just as formulated by Wirth (ref. 1), including 
the typography. This procedure, adapted from an 
ALGOL procedure published in the Algorithm depart- 
ment of Communications of the ACM (ref. 6), builds 
magic squares of odd order n when 1 <n < 16. 

Figure 4 is a syntax-defined and labeled relisting of 
the same PL360 procedure Magicsquare, less comments, 
with its typography determined by the rules already 
given for recognizing lines and their indentation. This 
relisting is independent of the typography of the pro- 
gram text in figure 3. It is expected that such a standard 
yet flexible form of program text will, in itself, help 


Figure 5.— Canonical data of 
Magicsquare. 


FILE KEY QUESTION 

1.34.1 AUTHOR OF PROCEDURE MAGIC SQUARE 7 

1.34.2 PURPOSE OF PROCEDURE MAGICSQUARE? 

1.34.3 INITIAL DATA? 

1.34.4 PRUCESSING LOGIC? 

1.34.5 FINAL DATA? 

1.34.6 REFERENCES? 

2.34.1 PURPOSE OF BLOCK 2,34 ? 

3.3.1 NSQR AT 3 ? 

4.4.1 N A 7 4 ? 

4.4.2 I AT 4 ? 

4.4.3 J AT 4 ? 

4.4.4 XX AT 4 7 

4.4.5 IJ AT 4 ? 

4.4.6 K AT 4 ? 

5.5, 1 VALUE OF NSQR AT 5 ? 

6.6, 1 VALUE OF R 1 AT 6 7 

7.7.1 VALUE OF NSQR AT 7 ? 

8.8. 1 VALUE OF I AT 8 ? 

9.9.1 VALUE OF J AT 9 ? 

10.33.1 PURPOSE OF FOR STATEMENT 10,33 ? 

10.33.2 FOR CONDITION AT 10 ? 

11.33.1 PURPOSE UF BLOCK 11,33 ? 

12.12.1 VALUE OF XX AT 12 ? 

13.13.1 VALUE OF IJ AT 13 ? 

14.14.1 VALUE OF XX AT 14 ? 

15.25.1 PURPOSE OF IF THEN STATEMENT 15,25 ? 

15.25.2 IF CONDITION AT 15 ? 

16.25.1 PURPOSE OF BLOCK 16,25 ? 

17.17.1 VALUE OF 1 AT 17 ? 

18.18.1 VALUE OF J AT 18 ? 

19.20.1 PURPOSE OF IF THEN STATEMENT 19.20 7 

19.20.2 IF CONDITION AT 19 7 

20.20.1 VALUE OF 1 AT 20 7 

21.22.1 PURPOSE OF IF THEN STATEMENT 21,22 7 

21.22.2 IF CONDITION AT 21 7 

22.22.1 VALUE OF J AT 22 ? 

23.23.1 VALUE OF XX AT 23 7 

24.24.1 VALUE OF IJ AT 24 7 

26.26.1 VALUE OF X « 1 J ) AT 26 7 

27.27.1 VALUE OF I AT 27 7 

28.29.1 PURPOSE OF IF THEN STATEMENT 28,29 7 

28.29.2 IF CONDITION AT 28 7 

29.29.1 VALUE OF I AT 29 7 

30.30.1 VALUE OF J AT 30 7 

31.32.1 PURPOSE OF IF THEN STATEMENT 31,32 7 

31.32.2 IF CONDITION AT 31 7 
32,32,1 VALUE OF J AT 32 7 
1,34,7 ANY FURTHER COMMENTS 7 


Figure 6.— Syntax-defined interroga- 
tion for Magicsquare. 


programmers read each other’s programs. 

Figure 5 shows the contents of the canonical data 
File generated by procedure Magicsquare. All further 
interrogation, response editing, and other documenta- 
tion processing will use this canonical data file and not 
the program text. This particular file contains 31 rec- 
ords with some 157 separate items of data in them: two 
coordinates, a syntactic type, and an average of about 
two identifiers per record. 

Figure 6 gives the syntax-directed interrogation of 
Magicsquare, using the canonical data file and the skele- 
ton questions of figure 2. There are 48 questions in all, 
which refer to the coordinates of the relisted program 
text and represent a systematic coverage of the text. 

A final question gives a programmer an opportunity to 
volunteer additional information not already solicited 
by the previous questions. 

Figure 7 contains a set of responses to the inter- 
rogation of figure 6. There is a file key associated with 
each question, which is used to label responses so that 
they may be indexed to the proper questions. The 
author has presumed to speak for “programmer 
Wirth” in constructing these responses. 

Figure 8 provides a resulting documentation re- 
port in the three sections described already: source 
code, edited responses, and cross-references. Fora 
short procedure or program such as this one, it is 


expected that a documentation report itself will be sufficient to allow a programmer to 


find out anything he wants to know about the procedure or program. 
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FILE KEY RESPONSE 

I|)M HI KLAUS MIRTH, STRNFQRD UNIVERSITY, DECEMBER 20, 196b. 

ESTABLISH A MAGIC SQUARE OF ORDER N , IF N IS 000 AND 1 < N < 16. 

1.34.3 THE ORDER, N, OF THE MAGIC SUUARE DESIRED, 

1.34.4 FILL SQUARE MATRIX Ml TH SUCCESSIVE INTEGERS ALONG CERTAIN DIAGONALS 
AND THEIR EXTENSIONS TU ENSURE MAGIC SQUARE PROPERTY. THE MATRIX TO 
BE FILLED IS ASSUMED TO CONTAIN ALL ZEROES INITIALLY. 

1.34.5 THE MAGIC SQUARE X AS A MATRIX IN LINEARIZED FORM. 

1.34.6 ALGORITHM U|, COMM ACM, AUGUST 1962, P 436; N. KRAI TCHIK . 
MATHEMATICAL RECREATIONS, P 149. 

2.34.1 CARRY OUT THE PROCEDURE MAG I C SQUARE . 

3.3.1 THE NUMBER OF ENTRIES IN THE MAGIC SQUARE. 

6.4.1 The ORDER I NUMBER OF ROMS RND CQLUMNSI OF THE MAGIC SQUARE. 

4.4.2 The HOP INDEX FOR THE NEXT INTEGEK VALUE GOI NC INTO THE MAGIC SQUARE. 

4.4.3 THE COLUMN INDEX FOR THE NEXT INTEGER VALUE COING INTO THE MAGIC 
SQUARE . 

4.4.4 INTERMEDIATE VALUE IN X OFFSET CALCULATION AND TO TEST X VALUE FOR 
ZERO. 

4.4.5 THE X OFFSET FOR ROM I, COLUMN J UF MAGIC SQUAME. 

4.4.6 THE NEXT INTEGER VALUE GOING INTO MAGIC SQUARE. 

5.5.1 INTERMEDIATE VALUE N FOR NSQR. 

6.6.1 TEMPORARY STORAGE OF NSQR 

2.2.1 FINAL VALUE OF NSQR. THE NUMBER OF ENTRIES IN THE MAGIC SQUARE. 

6<B,I INITIAL VALUE FOR I. 

9.9.1 INITIAL VALUE FOR J. 

10.33.1 FILL MAGIC SQUARE MlTH INTEGERS. 

10.33.2 STEP K THROUGH INTECERS FROM 1 TO NSQR, MHlCH MILL APPEAR IN THE 
MAGIC SQUARE. 

11.33.1 FIND CORRECT LOCATION IN MAGIC SQUARE FUR INTEGER K . 

12.12.1 X OFFSET FOR ROw I OF MAGIC SQUARE. 

13.13.1 X OFFSET FQR RQ a I AND COLUMN J OF MAGIC SOJARC. 

14.16.1 CURRENT VALUE OF POINT I, 3 IN MAGIC SQUARE. 

15.25.1 BEGIN MEM 01 AGONAL IF CURRENT DIAGONAL IS ALREADY FILLED. 

15.25.2 IS DIAGONAL FILLED IAN INTEGER ALREADY STORED AT POINT l,J|? 

16.25.1 FIND STAR TING LOCATICN FOR NEXT DIAGONAL TO BE FILLED. 

12.17.1 NEM ROM INDEX OF STARTING LOCATION. 
lB.ie.l NEM COLUMN INDEX OF STARTING LOCATION. 

19.20.1 RESTORE ROW INDEX TO CORRECT RANGE, IF NECESSARY. 

19.20.2 IS ROM INDEX OUT OF RANGE? 

20.20.1 ROM INDEX in CORRECI RANGE. 

21.22.1 RESTORE COLUMN INDEX TO CORRECT RANGE, IF NECESSARY. 

21.22.2 IS COLUMN IhOEX IN CORRECT HRNGE 1 

22.22.1 COLUMN INDEX IN CORRECT RANGE. 

23.23.1 X OFFSET FOR ROM 1 OF RAGlC SQUARE. 

24.24.1 X OFFSET FOR ROM I ANO COLUMN J OF N AG! C SQUARE. 

26.26.1 FINAL INTEGER VALUE AT POINT I, J IN MAGIC SQUAME. 

27,27, 1 ROM INDEX STEPPED ALONG 01 AGONAL. 

24.29.1 RESTORE «0m INDEX TO CORRECT RANGE. If NECESSARY. 

24.29.2 IS ROM I NOE X IN CORRECT RANGE 7 

29.29. 1 ROM INOEx IN CORRECI RANGE. 

30.30.1 COLUMN INDEX STEPPED ALONG DIAGONAL. 

31.32.1 RESTORE COLUMN INOEX TO CORRECI RANGE, IF NECESSARY. 

31.32.2 IS COLUMN INDEX IN CORRECT RANGE? 

32,32.1 COLUMN INOEX INCORRECT RANGE. 

1,34, T NO. 


Figure 7.— Interrogation responses for Magicsquare. 


MAGICSQUARE PROGRAM TEXT 

1 PROCEDURE MACICSOUAXE IRAK 

2 BEGIN 

3 SHORT INTEGER NSQR*. 

4 INTEGER REGISTER N SVN RO. I SYN R1 , J SYN 42 , XX SVN R). 
|J SVN R4, K SYN R5S 

5 NSQR «■ Hi 

6 R I l» N • NSQR ; 

7 NSQR III 

« l *- M * 1 SMRL U 

9 9 »• N; 

10 FOR X 1 STEP 1 UNTIL NSQR DO 

11 BEGIN 

12 XX >• I SHLL 6; 

13 13 I* J SHLL 2 » XX; 

14 XX XMJIj 

15 IF XX -« 0 THEN 

16 4ECIN 

17 l »■ l - i; 

IB j «■ j - 2! 

19 IF I < 1 THEM 

20 I j* l ♦ m; 

21 IF 3 < I THEM 

22 3 t. 3 ♦ Ml 

23 IX •• I SHLL 41 

24 13 •• 3 SHLL 2 • XI| 

25 END l 

24 XI 131 >• XI 

2? I !• I • ll 

24 IF I > N (MEN 

24 I «- I - Mj 

30 3 »» 3 ♦ l I 

31 IF 3 > N THEN 

32 J l> 3 - Ml 

33 END I 

34 END 

MAGICSQUARE EOITED RESPONSES 


FILE KET EDITED RESPOMCE 


4.4.1 
4.9. I 

10.31.1 

10.33.2 

11.33.1 

12 . 12.1 
13. 14,1 

14.16.1 

15.25.1 

15.25.2 

16.25.1 

17.17.1 
IB, I B, 1 
I9.2C.I 

19.20.2 
20 . 20.1 
21 , 22.1 

21.22.2 

22.22. 1 

23.23. 1 

24.24. 1 

26.24. 1 

21.27.1 

26.24. 1 

24.29.2 

29.29. 1 

30. 10. 1 
31. 32, 1 

>1.32,2 

32.32.1 

1.34.1 


VALUE GF NSQR AT T IS FINAL VALUE OF NSQR. THE NUMBER OF ENTRIES IN 
THE MAGIC SOUARE. 

VALUE OF I At • IS INITIAL VALUE F0« I. 

VALUE OF 3 At 4 IS INITIAL VALUE FOA 3. 

FOR STATEMENT 10.33 IS TO FILL MAGIC SQUARE NlTH INTEGERS. 

FQR COAOI T ION AT 10 IS TO STEP K IHAOUGH INTEGERS FROM 1 TO NSQR. 

MHlCH MILL APPEAR IN THE MAGIC SQUARE. 

BLOCK 11.33 IS 10 FIND CORRECT LOCATION IN MAGIC SQUARE FOR INTEGER X. 
VALUE OF XX AT 12 I S X OFFSET FOR ROM I OF MAGIC SQUARE. 

VALUE OF |J «| |3 IS X OFFSET FOR ROM I ANO COLUMN J Of MAGIC SQUARE. 

YALUl OF XX AT (4 IS CURRENT VALUE OF POINT l, 3 IN MAGIC SQUARE. 

IF THEN STATEMENT 15,25 IS TO BEGIN N£m OIAGOMAL IF CURRENT OlAGONAL 
IS ALREAOV FILLEO. 

IF CONDITION AT 15 TESTS IS DIAGONAL FILLEO IAN INTEGER ALREADY STOREO 
AT POINT 1,317 

BLOC* 14,25 IS TO F I NO STARTING LOCATION FOR NEXT DIAGONAL TO BE 
f ILLED. 

VALUE CF I AT 1/ IS MEM ROM INOEX OF STARTING LOCATION. 

VALUE CF 3 AT LB IS NEm COLUMN INDEX OF STARTING LOCATION. 

IF THE A STATEMENT 19.20 IS TO RESTORE ROM INCEX TO CORRECT RANGE. IF 
NECESSARY. 

IF CONDITION AT 14 It SIS IS ROM INDEX OUT OF RANGE? 

VALUE OF I AT 20 IS ROM INOEX IN CORRECT RANGE. 

IF THEN STATEMENT 21,22 IS TO RESTORE COLUMN INOEX TO CORRECT RANGE. 

IF NECESSARY. 

IF CONDITION AT 21 TISTS IS COLUMN INOEX IN COXRECI RANGE? 

VALUE OF 3 AT 22 IS COLUMN INDEX IN CORRECI RANGE. 

VALUE OF U 41 71 IS X OFFSET FOR ROM I Of MAGIC SQUARE. 

VALUE OF I J AT 24 IS X OFFSET FOR ROM I OF COLUMN 3 OF MAGIC SQUARE. 

VALUE OF Xllul AT 26 IS FINAL INTEGER VALUE AT POINT I. 3 IN MAGIC 

SQUARE . 

VALUE OF I AT J1 IS ROM I HUE X STEPPED ALONG DIAGONAL. 

IF THEM STATEMENT 28.29 IS TU RESTORE ROM INOEX TO CORRECT RANGE. IF 
NECESSARY. 

IF CONDI T I OM AT 2 B TESTS IS ROM INOEX IN CORRECT RANGE? 

VALUE OF I A I 29 IS ROM INOEX IN CORRECT RANGE. 

VALUE Of J AT 30 IS COLUNN INDEX STEPPED ALONG DIAGONAL. 

IF IHEM STATEMENT 31,37 IS TO RESTORE COLUMN INDEX TO CORRECT RANGE, 

IF NECESSARY. 

IF CONDITION AT 31 TESTS IS COLUNN INOEX IN CORRECT RANGE 7 
VALUE CF J AT )? IS COLUMN INOEX IN CORRECT RANGE. 

NO FURTHER COMMENTS. 


1,34, 

1,14, 


1.34 

1.34 

2.34 
3.3, 


4.6.5 

6.6.6 

>.5,1 


AUTHOR OF PROCEDURE MAGICSQUARE IS Ml KLAUS MIRTH. STANFORD UNIVERSITY. 
DECEMBER 20. 1464. 

PROCEDURE MAGICSQUARE IS TO ESTABLISH A MAGIC SQUARE OF ORDER N, IF N 
I S 000 ANO I < N < 26. 

INITIAL DATA OF PROCEDURE NAGICSOUARE IS THE OROER. N, OF THE MAGIC 
SQUAME DESIREO. 

PROCESSING LOGIC OF PROCEDURE MAGICSQUARE IS TO FILL SQUARE NATRIX 
■ UP SUCtSllVE INTEGERS ALONG CERTAIN OIACQMALS AND TMF I ■ . .« wY {NS ICKS 
iu thilMt MAGIC SQUARE PROPERTY. THE NATRIX TO RE FILLEO IS ASSURED 
TO CONTAIN ALL ZEROES INITIALLY. 

FINAL OAT A OF PROCEDURE NAGICSOUARE IS THE NAGIC SQUARE X AS A RATRIX 
IN LINEARIZED FROM. 

REFERENCES FOR MAGICSQUARE ARE ALGORITHM MB, COMM ACM. AUGUST 1462. 

P 6 36 S X. XAAITtMlA. RATHE NAT 1C At RECREATIONS. P 149, 

BLOCK 2.34 IS TO CARRY OUT THE PROCtOURE MAGICSQUARE. 

NSQR AT 3 IS THE NUMBER OF ENTRIES IN THE NAGIC SQUARE. 

N AT 6 IS THE ORDER INUMBER OF ROMS OR COLUMNS! OF THE MAGIC SQUARE. 

I AT 6 IS THE ROM INOEX FOR THE NEXT INTEGER VALUE GOING INTO THE 
MAGIC SQUARE. 

J AT 6 IS THE COLUMN I NOE I FOR THE NEXT INTEGER VALUE GOING INTO THE 
MAGIC SOUARE. 

XX At 6 IS INTERNED! ATE VALUE IN X OFFSET CALCULATION AMO TO TEST X 
VALUE FOR ZERO. 

1 3 AT 4 IS THE X OFFSET FOR ROM I, COLUMN J OF NAGIC SQUARE. 

K AT 6 IS THE NEXT INTEGER VALUE GOING INTO TME MAGIC SQUEAL. 

VALUE OF NSO* AT 5 IS INTERMEDIATE VALUE FOR MSQA. 

VALUE Of R I AT 6 IS TEMPORARY STORAGE OF NSQR. 


MAG 1C SUGAR I CROSS REFERENCES 
DATA CROSS REFERENCES 


I : OC A; AS 6,4.17,20.27,241 UA 7 .12 . 17 . 20,2 3. 27.291 UC 14,24; 
13 i DC 4; AS 13,24; UA 14,26; 

31 DC 4; AS 9.16.22.10.11 : U* .!?,»•• »2«24 . JO .31 1 UC 21. 31; 

X! DC 4;' AS 10; UA 10,26 J UC 10; 

NAGICSOUARE: OC 1 1 

N! OC 4; UA 5,4. a, 9. 20. 22. 29, 32; UC 24,31: 

NSQR 1 OC 3; AS 5.7s UA 6: UC lo; 

RO I UA 3,6. R, 4, 20, 22, 29, 32! UC 2R,31; 

Rlt AS 6.4. 1?. 20. 27, 29 l UA 7, 12.17,20, 21, 27, 24; UC 14.24: 

M2: AS 9,16,22.10,31; UA 13 . 14 ,22 ,24 . 30 , 31 ; UC 21.11; 

R3> AS 12.14.23; UA 13.24! UC 15: 

M4: AS 13,24; UA 14.26; 

R5: AS 10: UA 10,26; UC 10: 

R61 UC l: 

XI |J> : AS 26; UA 14; 

XII OC 4; AS 12,14.23; UA 11.24,; UC 15: 


.FUNCTION CROSS REFERENCES 


no function cruss references. 


PROCEDURE CROSS REFERENCES 


NO PROCEDURE CROSS REFERENCES. 


Figure 8.— Documentation report for Magicsquare 
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query: all references to k 

QUERY REPLY: 

4,4.6 K AT 4 IS THE NEXT INTEGER VALUE GOING INTO THE MAGIC SQUARE. 

10, J3, 1 FOR STATEMENT 10,33 IS TO FILL MAGIC SQUARE WITH INTEGERS. 

10,33,2 FOR CONDITION AT 10 IS TO STEP K THROUGH INTEGERS FROM 1 TO N$QR. 

WHICH WILL APPEAR IN THE MAGIC SQUARE. 

26.26.1 VALUE OF XIIJI AT 26 IS FINAL INTEGER VALUE AT POINT I.J IN MAGIC 
SQUARE. 

QUERY: ALL BRANCHES 
QUERY REPLY: 

10.33.2 FOR CONDITION AT 10 IS TO STEP K THROUGH INTEGERS FROM 1 TO NSQR. 

WHICH WILL APPEAR IN THE MAGIC SQUARE. 

It), 25, 2 IF CUNOIIION AT 15 TESTS IS 01 AGON AL FILLED IAN INTEGER ALREADY STORED 
AT POINT I.J! ? 

19.20.2 IF CONDITION AT 19 TESTS IS ROW I NOEX OUT OF RANGE ? 

21.22.2 IF CONDITION AT 21 TESTS IS COLUMN INDEX IN CORRECT RANGE 7 

20.2 9.2 IF CONDITION AT 20 TEST IS ROW INDEX IN CORRECT RANGE 7 

31.32.2 IF CONDITION AT >1 TESTS IS COLUMN INDEX IN CORRECT RANGc 7 

QUERY: ALL REFERENCES TO KEYWORD 'DIAGONAL* IN RESPONSES 
QUERY REPLY: 

1,34,4 PROCESSING LOGIC OF PROCEDURE MAGICSQUARE IS TO FILL SQUARE MATRIX WITH 
SUC E SS 1 VE INTEGERS ALONG CERTAIN DIAGONALS AND THEIR EXTENSIONS TU 
ENSURE MAGIC SQUARE PROPERTY, THE MATRIX TO BE FILLED IS ASSUMED TO 
CONTAIN ALL ZEROES INITIALLY. 

15.25.1 IF THEN STATEMENT 15,25 IS TO BEGIN NEW DIAGONAL IF CURRENT DIAGONAL 
IS ALREADY FILLED. 

15.25.2 IF CONDITION AT 15 TESTS IS 0 i AGONAL FILLED I AN INTEGER ALREADY STORED 
AT POINT I , JI7 

16.25.2 BLOCK 16,25 1$ TO FIND STARTING LOCATION FOR NEXT 0 i AGONAL TU BE 
F ILLED. 

27.27.1 VALUE OF 1 AT 27 IS RUW INDEX STEPPED ALONG DIAGONAL. 

30.30.1 VALUE OF J AT 30 IS COLUMN INOEX STEPPEO ALONG DIAGONAL. 

QUERY: ALL USES IN ASSIGNMENTS OF IJ 
QUERY REPLY: 

14.14.1 VALUE OF XX AT 14 IS CURRENT VALUE OF POINT I.J IN MAGIC SQUARE. 

26.26.1 VALUE OF XtfJI AT 26 IS FINAL INTEGER VALUE AT POINT I.J IN MAGIC 

SQUARE. 


Figure 9.— Some query replies for Magicsquare. 


Figure 9 indicates how certain queries might be used to probe more specifically into 
the procedure via syntactic, identifier, or response keyword criteria. Note in each case a 
subset of the edited responses of a full documentation report is simply compiled according 
to a query condition. 

In all these listings, the file keys have been listed to make the storage/retrieval process 
transparent. In practice, they could be suppressed in documentation reports and query 
replies. 
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DISCUSSION 

MEMBER OF THE AUDIENCE: Could you in the running program have asked some 
questions beforehand, such as what are the ranges of your variables, so that this could be 
incorporated into the program for error analysis? Could you also use this question-and- 
answer sort of thing for compiling optimization, so that you actually had a sort of interac- 
tive compiler? Do you think these kinds of things might be feasible? 

DR. MILLS: Well, I think they probably can. I have not thought about them, but I 
think that what you say sounds reasonable. I really laid out a very austere kind of thing. It 
is easy for the mind to boggle at the idea of trying to do computer-assisted interrogation of 
almost any subject. The computer programs are particularly well structured. I mean we can 
actually define the syntax. But doing this in other areas may be far-fetched. 

MEMBER OF THE AUDIENCE: How long would it take to develop this system? 

DR. MILLS: Well, what I described here to you is a paper system because we do not 
have PL360. But I hope I can get a couple of graduate students to do this quickly. 



